Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 013 / diskpack.arc / DISKPACK.DOC next >

Wrap

Text File | 1986-05-02 | 19.9 KB | 518 lines

╔═══════════════════════════════════╗ ║ Disk Packer - Version 1.00 ║ ║ ║ ║ Soft GAMs Software ║ ║ (c) Copyright 1986 ║ ║ ║ ║ G. Allen Morris III ║ ║ 1411 10th Avenue ║ ║ Oakland, CA 94606 ║ ╠═══════════════════════════════════╣ ║ FIDO #125/521 (ALLEN MORRIS) ║ ║ (415)647-8528 ║ ╚═══════════════════════════════════╝ TABLE OF CONTENTS INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1 WHAT THIS PROGRAM DOES The idea behind this program is to get the data on your disks into a form that DOS can read and write quickly. The first thing that is done to speed up finding the data is that all 'deleted' directory entrys are removed and the directory is packed, that is it will have no 'deleted' entrys. Doing this will speed up PATH search. The next thing to do is to de-fragment all of the data files and to put them into an order. There are several differant ways to order the files that are listed below. BACKGROUND PROGRAMS . . . . . . . . . 1 DATA LOSS . . . . . . . . . . . . . . . . . . . . . . . . . 1 POWER FAILURE . . . . . . . . . . . . . . . . . . . . . . . 1 LIMITS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 ORGANIZING YOUR DISK . . . . . . . . . . . . . . . . . . . . 3 RUNNING DiskPacker THE FIRST TIME . . . . . . . . . . . . . 4 INTRODUCTION This program started out in response to a comment that the public domain program STUFIT would not work on DOS 3.0 or above due to the way that MicroSoft was handling the allocation of disk space. In order to solve this problem I needed to use the direct disk I/O functions of MSDOS and handle the updating of the file allocation table (FAT) and directories. As a result I had the skeleton of a program that could sort the data on a disk in any order. At this point Mark Elfield came up with a algorithm to do this sorting and it was a simple process to implement it into the software that I had written to move files to the outer tracks. WHAT THIS PROGRAM DOES The idea behind this program is to get the data on your disks into a form that DOS can read and write quickly. The first thing that is done to speed up finding the data is that all 'deleted' directory entrys are removed and the directory is packed, that is it will have no 'deleted' entrys. Doing this will speed up PATH search. The next thing to do is to de-fragment all of the data files and to put them into an order. There are several differant ways to order the files that are listed below. BACKGROUND PROGRAMS The reason that you can not have BACKGROUND programs that read or write the disk is that the will not be able to find were the data on the disk is stored. Which will cause them to read garbage and to write to Clusters that are used by other programs. If a write were to occur large amounts of data can be lost as the director- ies can be over written. I am working on ways around this problem, but I have not come up with a good one yet. DATA LOSS In normal operation there should be no data loss, with the exception of write errors that are not detected by MSDOS if you have VERIFY set ON or use the /V switch. If you do not have VERFY ON and do not use the /V switch then no write errors will be detected. DiskPacker will run faster if it does not verify the data, But there is a greater chance of data loss. POWER FAILURE 1 In a power failure some problems can occur, but they can all be fixed buy running CHKDSK and DiskPacker. If a file is being moved there is only a problem if the power failure occurs between the time that the directory is written and the FAT is written, CHKDSK and recover all of the data as it will be in two places on the disk. To recover from this run 'CHKDSK /f' you will see the following: 1 lost cluster found in 1 chains. Convert lost chains to files (Y/N)? (Answer No) nnnn bytes disk space freed. You will then get the rest of the information from CHKDSK. If DiskPacker was moving a sub-directory then you may also see the message: d:\subdir\sibling Invalid sub-directory entry. This message is generated if the power failure occurred between writing the sub-directory and it's sibling. You may get messages stating that there are more than one invalid sub-directory entries. This is normal as long as they all are sibling of the same parent. There is only one other problem that can occur and that is if the power failure occurs between the time that the first FAT is written and the second FAT is written. If this happens the next time that you run DiskPacker you will see the message: FATs do not compare. (If you have not just run CHKDSK answer No) Would you like to fix FAT2? Answering Yes to this question will write FAT1 into FAT2 and you will be off and running. NOTE: It is always important to run CHKDSK after a power failure to correct any problems that may have occurred wether you were running DiskPacker or not. LIMITS Because the FAT and directories are read into memory there are some limits to there sizes. There must be less than 32000 clusters on the disk. If you have a disk with more than 32000 clusters write me or leave a message on one of the bulletin boards listed below and we can talk about getting you a special version of DiskPacker. 2 There also cannot be more than 2000 files any one directory. - Again if you have this problem I can probably modify the program to run on your disk. The only other limit is how much memory your computer has limits the total number of files that can be on the entire disk. Each directory entry takes about 34 bytes so if you have 300k of free memory you will be limited to about 8000 total files before you run out of memory. ORGANIZING YOUR DISK It is hard to say what is the best way to organize a disk as it will be different for each application. But I will try to describe some of the main considerations here. First we need a slight understanding of how MSDOS handles the files on a disk. Opening a file: When a file is opened DOS creates a FILE handle for the file. The number of file handles that can be opened is controlled by the FILES= command in your CONFIG.SYS file. In the FILE handle DOS saves information about were the data is stored on the disk. This involves reading the directory or directories if the file is not in the current directory and the FAT. Reading from a file: When data is read from a file DOS looks at the FILE handle to find the data and then reads the data into one of the buffers that were defined in the BUFFERS= command in the CONFIG.SYS file. If this data is read again it will be read out of this buffer and not off the disk. Writing to a file: When data is written to a file DOS looks to see if the data from the location that it is going to write to is in a buffer, if it is DOS over writes the buffer and then writes the data to the disk. If the data was not already in a buffer DOS will put the data into a buffer and then write it to the disk if this data is then read DOS will get the data from this buffer rather than the disk. Closing a file: When a file that has been written to is closed by DOS dos uses the data in the FILE handle which was updated by each write to update the directory entry for the file and update the FAT. We can see from this that the FAT and directory is only used when a file is opened or closed. Because of this it is not terribly important to keep the files on the outer tracks (close to the FAT) unless the file is opened and closed often. 3 So what files are opened and closed a lot? Well Batch files are opened and closed between each operation. EXE and COM files that are simple utilities such as ASK.COM are also opened and closed often. Overlay files are also opened and closed often, QMODEM would run faster if it's overlay files were on the outer tracks. Larger EXE and COM files should come after these as they are not opened and closed as often. All of these files almost never change in size and therefore will not become fragmented this also makes them good candidates for being put on the inner tracks of the disk. Many data files are opened once read many times and then closed. Most of the time on these files is spend reading the data and if there are not enough BUFFERS to hold the entire file the disk will have to be read repeatedly. So the location of these files is not very important but it is important that the data in the file is close together. Also if the file is used by a database manager and is indexed by another file we would want both of these files to be close together. In some applications there may be many files that are open at the same time and we would want all of them to be close together. The last type of file I can think of is a data file that is written to often. These files change size and become frag- mented. Yet many of these files have the same needs as the previous type. If these files are placed last DiskPacker will be able to de-fragment them faster and therefore they should be placed last on the disk. RUNNING DiskPacker THE FIRST TIME DiskPacker has been tested with MSDOS 2.10 and MSDOS 3.00. It has also been used on disks as big as 10 Megabytes. There is extensive testing done to make sure that the disk can be read and written and that the FAT and directories are in good repair. It is very unlikely that DiskPacker will hurt the data on your disk, but it is always a good idea to have the data on a hard disk on BACKUP disks or tape. There are several ways that DiskPacker can Optimize the data on your disk. They are as follows: Directory order. This puts the files onto the disk in the order that they are in the directories. You can use the TREE command to get a ruff idea of what this looks like. Packed order. This leaves the files in the same order as it finds them on 4 the disk. It will leave only one area of free disk space at the outer tracks of the disk. Fragmented order. This will put all of the files that are not fragmented on the disk first and will then put the fragmented files on the disk. Using this function will slowly put all of the files that change size on the outer tracks of the disk. You can use this function to get a similar effect to the special order function but it will take several passes over several days. Special order. This will let you put the files in any order that you want, leaving free disk space where you want. Normally PACKED order will do everything that you want. And for many user will be the only DiskPacker function that they will use. It is also the default function, if you run DiskPacker without any options this is the function it uses. Unless you have a special application you are using you computer for or you are a real speed freak you should just run DiskPacker with either the Packed order or Fragmented order function switch. DP /P or DP /F. I will go no farther with the Directory order function as I do not think it is of much use and is manly included to make this program compatible with the competition. Ok so you want you files to be just so. You need to use the Special order function. In order to do this you will need to make a file that lists the files in the order that you want them on the disk. Files need to have there full path names included. Sub- directories are treated as files and not as a wild card pointing to all of the files in the sub-directory. There is also a switch that can be included to tell Disk-Packer where to leave free space. The utility DPMAKE is included to help you make this file. You may also need a text editor that has a non-document mode to sort, delete or add to this file. The default name for this file is "DISKPACK.DPD". And it should be in the ROOT directory of the disk being worked on, or you can also give DiskPack the name and path of the file you wish to use. Below is a sample of what this file should look like. \COMMAND.COM Comments can go here \AUTOEXEC.BAT \PROG1.OVL 5 \PROG2.OVL \SUBDIR_A\PROG1.OVL This is different than \PROG1.OVL \SUBDIR_A \SUBDIR_B All unnamed files will be after \SUBDIR_B and will be handled in the in the same way as the Pack order function handles files (see above). Of course if all of the files are named in this file there won't be any files to order. /FREE This tell DiskPacker that the rest of the files should be placed on the inner tracks. \CONFIG.SYS This will be the last file on the disk and its last cluster will occupy the last cluster on the disk. \DISKPACK.DPD You can include this file. \diskpack.bak This will be the third from the last file on the disk. As you can see it will take some work to make this file. The DPMAKE utility can help you make this file. Basically DPMAKE is a WHEREIS program. The differance is that it outputs the full path name along with the file or sub-directory name. it output goes to the standard output device. So you can either run DPMAKE *.* and then use your text editor to sort the data or you can run DPMAKE something like this: DPMAKE command.com > \diskpack.dpd DPMAKE autoexec.bat >> \diskpack.dpd DPMAKE *.ovl >> \diskpack.dpd DPMAKE SUBDIR* >> \diskpack.dpd copy con >> \DISKPACK.DPD \FREE ^Z DPMAKE CONFIG.SYS >> \diskpack.dpd DPMAKE DISKPACK.DPD >> \diskpack.dpd This would give you a file resembling the DISKPACK.DPD sample above. DiskPacker ignores multiple file name, so this is OK: DPMAKE FILE*.COM >> \diskpack.dpd DPMAKE *.COM >> \diskpack.dpd This would put all files that match FILE????.COM in to DISKPACK.DPD and then put in all the *.COM files. SAMPLE.BAT has a sample of a good way to run DPMAKE. After you have gotten DISKPACK.DPD made you can run DiskPacker. 6 Use the following command: DP /S If you want to use a different filename than "\DISKPACK.DPD" you can use: DP /S path\filename.ext 7 INDEX /V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 BACKGROUND PROGRAMS . . . . . . . . . . . . . . . . . . . . . 1 DATA LOSS . . . . . . . . . . . . . . . . . . . . . . . . . . 1 DOS I/O Closing a file . . . . . . . . . . . . . . . . . . . . . 3 Opening a file . . . . . . . . . . . . . . . . . . . . . 3 Reading from a file . . . . . . . . . . . . . . . . . . . 3 Writing to a file . . . . . . . . . . . . . . . . . . . . 3 DPMAKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 FAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 File allocation table . . . . . . . . . . . . . . . . . . . . 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 1 LIMITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 ORGANIZING YOUR DISK . . . . . . . . . . . . . . . . . . . . . 3 POWER FAILURE . . . . . . . . . . . . . . . . . . . . . . . . 1 RUNNING DiskPaker THE FIRST TIME . . . . . . . . . . . . . . . 4 VERIFY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 WHAT THIS PROGRAM DOES . . . . . . . . . . . . . . . . . . . . 1 8